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STGT (Second TDRSS Ground Terminal) is currently halfway 
through the System Integration Test phase (Level 4 Testing). To 
date , many software architecture and Ada language issues 
have been encountered and solved. This paper, which is a 
transcript of the presentation at the December 3rd meeting , 
attempts to define these lessons plus others learned regarding 
software project management and risk management issues, 
training, performance, reuse, and reliability. Observations are 
included regarding the use of particular Ada coding 
constructs, software architecture trade-offs during the 
prototyping, development and testing stages of the project and 
dangers inherent in parallel or concurrent Systems, Software, 
Hardware and Operations Engineering. 
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Introduction 

STGT is the first major Ada development 
program for M&DSO, which has devel- 
oped other large ground stations in FOR- 
TRAN and C. in addition to the use of Ada, 
GE Management and Data Systems Oper- 
ations faced other software development 
risks in the implementation of STGT. Some 
of these risk items are itemized below: 

• A heavily distributed system ( > 30 
processing nodes and >100 worksta- 
tions in previous ground stations) 

• High real-time system content (vs. 
40% real-time, 60% batch process- 
ing) 

• First on a DEC/VAX platform (vs. IBM 
mainframes and Sun/Unix worksta- 
tions) 

• High-availability/high-reliability archi- 
tecture (99.99% availability required) 

• High hardware content ( > 350 racks 
of ground communication equipment) 

• Heavily automated, X-Windows, 
workstation-based user interface 

• First artificial intelligence (Al) based 
hardware fault detection/fault isolation 

• Short development lead time (3 years 
from start to delivery) 


Risk items like the above don’t usually 
translate into the impossible, they just have 
a way of eating into cost and schedule mar- 
gins. Several steps were taken to mitigate 
the risks involved. An Ada Core Team was 
formed prior to program startup to develop 
language expertise. An Ada training pro- 
gram was developed and its completion 
required for ail software engineers 
employed on the program. Despite these 
efforts, many lessons were learned on the 
job through prototyping, development and 
testing. This paper is intended to be a 
chronicle of these risk issues and (hopeful- 
ly) their resolutions. 

Project Composition 

The Second TDRSS (Tracking and Data 
Relay Satellite System) Ground Terminal 
(STGT) is a new ground station and an up- 
grade to an existing ground station in White 
Sands, New Mexico. These ground sta- 
tions will provide command and data com- 
munications from user control facilities 
through the TDRS, and on to the various 
user satellites and the Space Shuttle. 

The breakdown of thousands of source 
lines of code developed for each Comput- 
er Software Configuration Item (CSC!) for 
the project is shown in Table 1 . 
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CS-CI 

Size (Lines of 

Thousands of Hours 1 

LOC / Hour 

TTC (Satellite Control) 

100k 

115k 

0.86 

DIS (Communication) 

76 

79 

0.96 

USS (Ground Equip.) 

71 

58 

1.22 

EXC (Scheduling) 

26 

23 

1.13 ”1 

WKS (Workstation Inter- 
face) 

152 

56 

2.70 

COM (Infrastructure) 

23 

37 

0.62 

MDS (Development Env.) 

100 

36 

2.77 

SIM (Simulators) 

40 

40 

1.00 

Totals 

588 

444 

1.32 


Note: 

1 - Requirements Analysis through Software Test 


Descriptions of the CSCIs are as follows: 

• TTC: 

Tracking, Telemetry and Command 
CSCI, responsible for controlling the 
Tracking and Data Relay Satellites 
(TDRS) used by NASA to relay user 
satellite and space shuttle telemetry 
and command data. Responsible for 
commanding the satellite, monitoring 
its health, and controlling the ground 
antenna in order to point at the satel- 
lite. 

• DIS: 

Data Interface Subsystem, responsi- 
ble for interfacing with the NASA com- 
munication network, accepting sched- 
uling orders from NASA, and 
switching the inputs and outputs from 
the ground station to data links be- 
tween STGT and the other NASA lo- 
cations. 

• USS: 

User Services Subsystem, responsi- 
ble for controlling most of the ground 


communications equipment (GCE) 
and supporting communications to 
the TDRS and to various user satel- 
lites. 

Executive, responsible for scheduling 
of a single Space to Ground Link Ter- 
minal (SGLT) controlling a single 
TDRS satellite. There will be six 
SGLTs overall in the two ground sta- 
tion installations. 

• WKS: 

Workstation, responsible for operator 
interface, including intelligent graphi- 
cally-oriented displays, operation 
alert messages and operator com- 
manding capabilities. 

• COM: 

Common Run-time Environment, 
provides common capabilities across 
all computers including communica- 
tions within and between computers, 
data logging, startup/shutdown/ 
failover control, and device driver in- 
terfaces. 
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• MDS: 

Maintenance and Development Sub- 
system, provides COTS tools for de- 
velopment and maintenance environ- 
ment, database displays/editors, and 
configuration management software. 

• SIM: 

Simulations, provides simulations of 
the NASA scheduling interface, 
ground hardware, and the TDRS. 
Simulators are used in testing, train- 
ing and problem investigation. 


Software Architectural issues 

Architectural Reuse 

STGT attempted a high level of reuse and 
incorporated reuse into its architecture, 
and in many ways succeeded. Attempts 
were made in object-oriented design, 
some of which succeeded in providing reli- 
able, understandable, reusable products, 
and some of which only caused major 
headaches. Those that were problematic 
were usually related to lack of understand- 
ing of the scope and breadth of the situa- 
tions in which the code would be reused, 
the computers on which the code would 
run, and the environments on these com- 
puters. For example, code reused on a 
workstation found itself in a rather different 
environment than on the large VAXes, due 
to lack of availability of large local data- 
bases. 

Reuse was attempted on both large and 
small scales. Small-scale reuse was of 
course more easily planned than large- 


scale reuse. Large-scale reuse was more 
likely to result in complicated error condi- 
tions, where different subsystems (and 
their engineers and programmers) wanted 
to operate in different ways but were con- 
strained by identical implementations due 
to code reuse. 

Ada Reuse 

In the early days we had “reuse evange- 
lists” who proposed massive, complex, 
self-initializing generics for everyone. Al- 
most every case that was ever implem- 
ented was later disabled, deleted, gutted 
or otherwise rewritten. Generics proved 
very difficult to debug using a source-level 
interactive debugger, relatively slow to ex- 
ecute in real-time, and very hard to write. 
Elaboration time-initialization code was 
also difficult to debug and prone to excep- 
tion handling difficulties. Simple generics, 
on the other hand, were often very effective 
and easy to reuse. Complicated generics 
(including generics within generics within 
generics) were seldom worth the cost un- 
less the designer and sole user were one- 
and-the-same, and the designer was well 
above-average in terms of proficiency and 
experienced at writing generics. That’s not 
to say that we didn’t have proficient pro- 
grammers. With 100 or more program- 
mers, just don’t expect everyone to be a 
generics expert and design generics well. 

Our best use of complex Ada generics in- 
volved data logging and retrieval software. 
This software utilized a high number of ge- 
nerics starting with primitive types (strings, 
integers, reals) and built up by instantiation 
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into complex, compound record struc- 
tures in various sizes and formats. This 
worked very well, provided a single desig- 
ner/programmer was responsible for both 
the generic capability and it’s uses. 

Other good choices for Ada generics were 
design elements which clearly had a high 
degree of parallelism , such as our commu- 
nications package which treated all mes- 
sages the same, regardless of individual 
message formats. These even utilized de- 
clare blocks, which instantiated the generic 
on-the-fly for differing sizes or other re- 
cord discriminants based on run-time val- 
ues. These met with good success and 
surprisingly good performance on VAX 
Ada. Poor choices included the hardware 
simulators, which attempted a very high 
degree of generics ( > 50% of code was 
within a generic) which suffered from se- 
vere performance penalties and lack of 
flexibility in dealing with specific hardware 
behaviors. 

Coding to a common source template is 
actually a low-tech form of reuse that 
should not be overlooked. It worked very 
easily (as long as the template was correct) 
and served to promulgate good examples 
for coding and error-handling. Templates 
were used for declaring, sending and re- 
ceiving message objects. They worked 
well, until limitations in the templates were 
found. A more extensive effort in develop- 
ing the template would have payed off 
handsomely in our experience. 

Avoid “Monolithic” Ada packages. Trying 
to be all things to all people will most likely 


be nothing to anybody. Thinking that ob- 
ject-oriented design translates into “throw 
everything into one package” is similarly 
misguided. Use a layered approach in- 
stead. Define a package with just type defi- 
nitions. Then define a package that pro- 
vides basic operations on these types. 
Define higher-level packages as neces- 
sary to define more complex operations, 
building on lower-level packages. A care- 
ful architecture like this can help you reap 
big reuse benefits as new uses are found. 

Following this approach allows different 
programs to access the object at different 
layers of abstraction. Some just need a 
type definition. Others need basic routines 
to manipulate the types. Some need ad- 
vanced routines composed out of basic 
routines. Others could benefit from auto- 
matic initialization of objects at elaboration 
time (tends to be very trouble-prone, 
should be carefully controlled by a stan- 
dards committee). All uses of a complex 
object, especially potential future ones, 
may suffer if the only view presented is a 
single complete monolithic view. A pro- 
gram wishing access to a type definition 
ends up with pages of “hidden”, unused 
code and data, and maybe even automatic 
creation/initialization of objects at startup 
time, referencing databases defined on 
one computer and not others. 

Variable-length strings were another good 
reusable package. We implemented them 
with a generic package, pre-instantiated 
sized to 256 characters. Use of a pre-ins- 
tantiated package allowed easier sharing 
of types. However, this also encouraged 
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waste (programmers were encouraged to 
use 256-byte strings where only 16 char- 
acters were necessary). 

Ada Architecture issues 

Error handling was our number-one archi- 
tecture problem. We definitely could have 
benefitted from better up-front design and 
more prototyping. Ada tasks complicated 
the error handling picture drastically. 

There is a lot of functional overlap between 
the capabilities provided by Ada excep- 
tions and those provided by VAX/VMS 
Condition handlers. There were points of 
interference or undesirable interplay be- 
tween the two as well. You need to design 
error handling into all system service calls. 
Know which exceptions are worth handl- 
ing, and which you WANT to be unhandled 
(because they show up obvious coding or 
environment problems). 

Taking advantage of the operating sys- 
tem’s capabilities for calling stack trace- 
backs on unhandled exceptions, for ex- 
ample, can provide lots of power for 
debugging. These are especially useful if 
integrated into the debugging environ- 
ment, as is the case with most DEC/VAX 
software. 

Concurrency 

Ada Tasks 

Much fear was generated during early de- 
sign phases concerning the trade-offs be- 
tween concurrent operating system pro- 
cesses, and concurrent Ada tasks. During 


implementation, use was made of both 
single and multiprocessor machines, with 
varying results. Software testing and mod- 
ification history have allowed us to con- 
struct better guidelines for process versus 
task trade-offs. In many cases, processes 
were used as an aid to work breakdown 
rather than based on strong architectural 
need. In some cases these choices 
caused problems later, and limited the 
range of available solutions for require- 
ment or design changes. Ada tasking 
would have been more flexible. 

However, increased use of Ada tasking 
would have required a different develop- 
ment support structure. This support 
structure would have had to allow separate 
development and testing of task-based 
functional work packages independently. 
The tasks could then be integrated into a 
single process resulting in a more reliable 
system. 

In general, tasks were well-used and 
caused relatively few problems. Among 
the problems were prioritization, blocking, 
proliferation of tasks required to synchro- 
nize between other tasks, and increased 
rigor in defining/testing the tasking archi- 
tecture. Tokens (Ada “private” objects 
containing pointers and flags used in the 
interface packages between application 
and service layers) were used to define 
message addresses. These later became 
a problem since they were not designed to 
be shared, yet were shared in some appli- 
cation programs among various tasks. 
The sheer number of tokens used in the 
system prevented us from embedding a 
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task within all token types for synchroniza- 
tion (because of the amount of memory 
used for task stacks, etc.)* but we later em- 
bedded “token in-use” flags to help detect 
instances of sharing. Earlier recognition of 
the problem would have allowed a range of 
more elegant solutions. 

The following are some additional observa- 
tions regarding Ada tasks: 

• Task context switches are a LOT fast- 
er than process context switches. If 
you’re thinking of adding more pro- 
cesses, tasks are better. However, 
processes are easier to split up the 
work among multiple independent 
programmers. Tasks in the same 
process require more programmer 
coordination during development. 

• Tasks are like lawyers. If you have no 
tasks, you probably won’t need any. 
However, once you have two tasks, 
you will probably need another five or 
ten more to handle coordination be- 
tween those two tasks plus synchro- 
nize any shared inputs, outputs, re- 
sources, etc. This means that if you 
start out thinking that you’ll write a 
program with a few tasks, you’ll prob- 
ably end up writing lots. However, 
this didn’t appear to have been a 
problem. The number of tasks did 
not affect performance as long as 
they were event-driven. You may 
have to spend more time maintaining 
relative priorities of tasks as the num- 
ber increases. 

• We avoided PRAGMA TIME_SLICE, 
since we understood it to add signifi- 
cant overhead. We were successful 


in avoiding it. Several times we were 
tempted to use it to alleviate other 
tasking problems, but it was never 
absolutely necessary and in the end 
was successfully avoided. 

• Multiprocessor problems were en- 
countered, which required us to use 
PRAGMA SHARED and PRAGMA 
VOLATILE, which are implementation 
dependent. These relied on archi- 
tecture-dependent features of VMS 
processors. The features worked well 
in our two-CPU environment. 

• We would have liked to prioritize dif- 
ferent entry points in the same task 
(e.g. to handle the same type of ren- 
dezvous, but from different sources), 
but Ada doesn’t allow it. We found a 
kludgy way of doing it. Instead of at- 
tempting reuse, we should have dupli- 
cated the task code ( i.e. via task 
types) and prioritized them differently. 
Maybe we did this because we were 
attempting excessive reuse, or we 
were afraid of proliferating tasks. 
Simpler would have been better. 

• We worried a lot about "fairness” of 
tasking, however all fears appeared to 
be groundless. If you’re worried 
about fairness of tasking, what you 
really may be worried about is that 
you need more CPU power. Or you 
may have tasks polling when instead 
you need to turn them around into an 
interrupt-driven approach. 

• Beware of non-reentrant servers, ser- 
vices, etc. Accesses to Rdb, the rela- 
tional database we used, had to be 
serialized by routing all task’s re- 
quests through a single Rdb server 
task (gateway) which in turn provided 
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the sole control of the Rdb server. 

This is a fairly common problem inter- 
facing with non-Ada facilities for 
which you should watch. Our COTS 
Graphical User Interface (GUI) non- 
reentrancy problem was solved with 
the opposite approach. We ran four 
copies of it, one for each operator 
window. 

• There was still some question for us 
about what Delay 0.0 really did, or if it 
was necessary. It was documented 
as a way to break the execution of a 
long-running task and allow a context 
switch to another waiting task. When 
we attempted to verify this behavior 
through benchmarks however, we 
met with mixed results. We eventually 
opted not to use the feature. Instead 
we broke problematic long-running 
tasks into multiple shorter tasks. 

We also had reports of problems with 
the fairness of allocation of CPU time 
among tasks. When we investigated 
with benchmarks, however, all we 
found were problems with the bench- 
marks. For each case of purported 
probems with Delay 0.0 and tasking 
fairness, programmers who thought 
they had a problem with an Ada fea- 
ture were instead using too much 
CPU time. The ultimate fix was to 
rearchitect the program to respond to 
events or Asynchronous System 
Traps (ASTs) rather than poll. 

Compile-time vs. Run-Time Binding 

• You can use unchecked_conversion 
to convert between system. address 
and object_access types. You’d bet- 


ter be very careful when using this, 
though. A LOT of errors were com- 
mitted in this area. Need careful code 
review and on-the-job indoctrination, 
perhaps through programmer peer 
group inspections/walkthroughs, etc. 
Watch out for things like unintentional- 
ly overlayed objects and other C code 
type pointer errors. 

• Anytime you use access types or sys- 
tem addresses in variables it opens 
the door for memory leaks around al- 
location/deallocation . 

• The Ada compile-time binding of re- 
cord types was an early problem 
when data logging record types were 
very volatile. Many low-worth recom- 
pilations were performed. Configura- 
tion management and test computer 
system performance were impacted 
by the need to accept the many new 
executables images that were gener- 
ated. A run-time-binding architecture 
might have been better in these highly 
volatile report-writing cases. Once 
the formats stabilized, the structure 
did provide for ease of checking. 
Compilation tests for code impact to 
changing interface or record format 
become both routine and precise. 

Message Passing Architectures 

Ada Interface Definitions 

Internal interface definitions, between 
computers and software subsystems, 
were captured in Ada. In most cases, re- 
presentation clauses were not used. In- 
stead the message record definition code 
was reused in each subsystem. Software 
configuration management mechanisms 
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ensured that interfaces were modified con- 
sistently. This was reliable since all com- 
puters used the same hardware architec- 
ture and the same compiler. 

Platform Dependencies 

Operating System Dependencies 

Many unknown, unforseen platform de- 
pendencies cropped up during the devel- 
opment and test phases. In many cases, 
these problems were the most astounding 
and difficult to predict of any we encoun- 
tered. There is a high degree of functional 
overlap between the Ada compiler/lan- 
guage run time environment (VAX/VMS 
Ada 2.2-41 at this writing) and the host/tar- 
get operating system (VMS 5.5-1). This 
overlap caused problems in error handl- 
ing; Ada exception handling interfered with 
the generation of otherwise automatic op- 
erating system calling-tree tracebacks. It 
also appeared in process management 
(computer operators couldn’t reliably can- 
cel processes with some types of tasking 
structures), and debugging (generics and 
tasks increased difficulty of source-level 
debugging and thus were unpopular with 
programmers) . While many of these are 
platform-dependent, they point to the 
overall problem of overlap between Ada’s 
functionality and the functionality of the op- 
erating system upon which it’s running. If 
you’re running on a bare-bones proces- 
sor, or a primitive operating system, then 
there may be little or no problem. Using a 
sophistcated and feature-rich operating 
system like VAX/VMS, on the other hand, 


can lead to limitations and unforeseen 
problems when you use Ada’s advanced 
features and the operating system’s ad- 
vanced features in the same program. 

We ended up having our DEC consultants 
write a sophisticated assembler routine 
embedded in each executable which de- 
tects unhandled exceptions in any task, 
forces a traceback, and terminates the 
image. This has provided us with vastly im- 
proved turn-around time for fixing fatal er- 
rors found during testing. 

Some particulars we found: 

• The VAX Ada Run Time Library dis- 
ables certain features of VMS (like the 
capability of a computer operator to 
stop a process gracefully, unless 
you’ve coded-in your own user-de- 
fined exception handler and a means 
to signal termination). Also, VAX 
Ada’s memory deallocation/stack un- 
wind during exception propogation 
interfere with VMS’s capability to do a 
call tree traceback, which would 
otherwise have shown a stack dump 
from the line raising the problem all 
the way back up to the top of the pro- 
gram. This was especially trouble- 
some when some tasks failed due to 
unhandled exceptions, (coding er- 
rors), but other tasks and the process 
as a whole, continued to function, 
making it difficult to detect and isolate 
the problem. 

• Writing debug or error messages us- 
ing Put_Line caused a performance 
problem in real-time processes, when 
all tasks in the process hang behind 
an operating system output request 
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queued to the disk device. We 
couldn’t tolerate this in many of our 
hard-real-time executables, so we 
converted these into shared memory 
messages between the real-time pro- 
cesses and a lower priority server 
process, who performed output on 
behalf of the real-time processes. 

We used tuned Record Management 
Services (RMS) Input/Output instead 
of vanilla Ada TEXTJO or SEQUEN- 
TIALJO. This was because of the 
need for heavy-duty tuning, including 
buffering control and management. 
We implemented a Mixed l/O-like ca- 
pability using discriminated records, 
where each record in the file con- 
tained its own embedded record for- 
mat identifier. This worked quite well, 
except when the formats were under 
early development and changed of- 
ten. Then backward compatibility of 
current software and previously ar- 
chived data files became tedious. 

SHARED images (a sophisticated 
VMS Feature) wouid have been good 
to use in certain areas where reusable 
code made up almost a Megabyte of 
each executable image, but the inte- 
gration with Ada was not smooth. By 
the time we developed a good work- 
ing approach we had to abandon it 
because of the retrofit cost. This 
might have helped Ada’s perform- 
ance some, in decreasing the 
memory required, if it could have 
been done earlier with benefits amor- 
tized over more of the development 
phase, it would have saved money 
and time. We had initial misgivings 
about the ability to debug an installed 


shared image, which later appeared 
to have been unfounded. 

• VMS has a very nice software pseu- 
do-interrupt capability (Asynchronous 
System Traps or ASTs). The Ada 
run-time library uses these to do it’s 
own synchronization, and instead 
converts each application AST into a 
task rendezvous. As a result, running 
Ada as a part of a “real” AST such as 
in a call from a device driver written in 
another language was a difficult prop- 
osition (couldn’t use tasking, perform 
any I/O, etc.). However, the run time 
libary’s conversion of ASTs to tasks 
(PRAGMA AST ENTRY) was quite ac- 
cessible to programmers. Tasks 
seemed to be quite easy (and even 
natural) to use for this purpose. This 
enabled anyone to make use of ASTs, 
whereas without this we probably 
would have had to restrict their use to 
an elite group of the most experi- 
enced programmers. 

• Make use of platform capabilities. 
Don’t be an Ada zealot, thinking you 
have to write pure Ada code and du- 
plicating functionality otherwise avail- 
able more cheaply or efficiently in the 
operating system (100% code porta- 
bility wasn’t an issue for us - and it 
may not be for you either). Examples 
are character and numeric utilities. 
Just write good (portable) package 
specs, and implement the bodies of 
these in the most efficient manner, 
even utilizing operating system ser- 
vice calls or non-Ada utility packages. 
This is especially appropriate on com- 
plex instruction set computers (CISC) 
like the VAX. You can always rewrite 
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the bodies for each new platform to 
which you port. That way you’ve ad- 
dressed performance, reusibility and 
reduced risk while making good prog- 
ress and leveraging the capabilities 
and strong points of your underlying 
platform. 

COTS Dependencies and Integration 

During the proposal phase of STGT we 
identified several areas where Commer- 
cial Off-The-Shelf (COTS) software could 
be used. We then deleted costs based 
on the difference between developing the 
application from scratch and the cost of 
the COTS product. However, the follow- 
ing concerns arose: 

• We did not allocate necessary addi- 
tional costs to continually evaluate 
and incorporate periodic updates/up- 
grades of these COTS products. This 
turned out to be a big ticket item over 
the life of STGT. 

• Purchase good quality COTS bind- 
ings. This is a LOT of work. Availabil- 
ity/maturity of Ada bindings should be 
a significant discriminator during 
COTS evaluations (e.g., XWindows/ 
Motif binding problems, Distributed 
File Service (DFS) bindings, device 
driver bindings, etc.). As usual, pro- 
ductivity may be gained for many at 
the expense of hard work by a few, or 
by the purchase of a proper bindings. 
Consider the trade-offs. 


Performance 

Ada Performance Characteristics 

Many performance problems were en- 
countered which required various mitiga- 
tion approaches. Performance modelling 
was only as good as the input received 
(much guess work was necessary early on 
in the life-cycle). This lead to big surprises 
and varying types of late changes. Eventu- 
ally larger CPUs and more memory were 
purchased. 

There appears to be a SERIOUS dichoto- 
my in Ada between coding for perform- 
ance and coding for what most consider to 
be a “good” Ada style. “Good” Ada was 
subject to our interpretation of the current 
literature and to the lessons developed 
during prototypes by the Ada Core Team. 
What might be considered “good” Ada of 
course will change over time. Examples 
are: 

• The generic string package was pre- 
instantiated for (discriminated record 
structures) of 256 bytes. This affords 
maximum reusability and similarity, 
but appears to waste memory and 
disk space due in certain cases to 
needlessly large structures. 

• Proponents of “good” Ada often 
stress deeply nested procedure calls 
for modularity and reuse. “Fast” Ada 
is often relatively flat, with a shallow 
call depth. 

• “Good” Ada makes maximum use of 
local variables. “Fast” Ada allocates 
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variables once in package bodies, 
then carefully reuses them within 
package procedure and function bo- 
dies. 

• “Good” Ada makes maximum use of 
Generics. “Fast” Ada avoids complex 
generics. 

• Good Ada makes minimum use of im- 
plementation-dependent PRAGMAS. 
Fast Ada utilizes some PRAGMAS, 
e.g., PRAGMA ELABORATE to force 
elaboration of packages before the 
routines are called for real-time ex- 
ecution. 

• As a result of the apparent quandry 
between “good” and “fast” Ada, it 
seems that Ada right out of the ob- 
ject-oriented training book can be 
quite slow. You either need to allocate 
a bigger CPU, know very accurately 
the performance characteristics in ad- 
vance, or plan on a tuning phase to 
increase the performance of your 
code once it’s written. 

Schedule pressures made us opt for the 
quickest solutions in most cases, that is, 
larger CPU’s. We had some success in op- 
timizing Ada for performance. In some 
cases the re-coding or reimplemetation of 
a component saved 50-100% of CPU or 
Memory resources. In one case it saved a 
factor of 5X CPU for a compute-intensive 
satellite orbit prediction function. 

Configuration Management 

Ada Configuration Management 

• Ada dependencies are GRAPHS, 
most library structures/directory hier- 


archies are TREES. Therefore, if you 
lock yourself into a library structure 
that mimics the Ada dependency 
structure, you’ll be disappointed 
eventually. We used a simple tree of 
SHARED code at the top, with CSCIs 
or subsystems below. 

• Sublibraries were used versus the 
VAX Ada Compilation System (ACS) 
ENTERED units. This allowed auto- 
matic recompilation for dependent 
units when root units changed. The 
downside was that massive recompi- 
lations were forced when not all de- 
pendent libraries (and groups using 
those libraries) were ready to see the 
change. An alternative approach 
might have been to develop a tool for 
automatically re-entering changed 
units into dependent libraries. That 
also could have allowed for library de- 
pendencies more complicated than a 
tree. 

• We used separate/duplicate libraries 
to reflect differing levels of software 
test maturity. For instance, we had 
one shared set of libraries in which 
developed code. We only updated 
the reused components of that library 
once a week. People affected by in- 
terface changes only had to support 
(or suffer) changes once a week. 

• We could have used hierarchical li- 
braries for test, but the computational 
requirements were too great. Our de- 
velopment CPU resources were never 
great enough to compile the same 
source code multiple times for differ- 
ent hierarchical libraries supporting 
different test maturities. Consequent- 
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ly all tests were forced to the same 
maturity - fresh from the programmer. 

• We had to write a program to extract 
a cross-reference containing "where- 
used” information. ACS did not pro- 
vide this information. 

Ada Compilation Performance 

We did a LOT of work to improve compila- 
tion speed. Some of the things we did 

were: 

• Faster CPUs - went from VAX 8250s 
(1 .5 MIPS) to VAX 6610s (25 MIPS). 

• More memory - from 64 to 256 Mb 

• Tuning of system quotas, batch 
queues etc. 

• RAM DISK and/or semiconductor disk 
for shared code Ada library (most crit- 
ical compilation library) 

• Spread I/O over multiple disks to re- 
duce bottlenecks 

• We didn’t persue but maybe should 
have experimented further with the ef- 
fects of smaller and larger directory /li- 
brary sizes on compilation speed. 

Ada Compiler 

• We found relatively few bugs. Most 
were in code generation, a few for 
floating point types and others which 
optimized away variables or code. 

One involved different Ada library unit 
interfaces depending on whether 
code was compiled in debug or non- 
debug. All were resolved in quite 
good order by excellent DEC support. 
The lesson was that compiler maturity 


(for VAX/VMS Ada) was not a risk fac- 
tor. We also learned that run-time (vs. 
compile-time) bindings for certain 
rapidly and persistantly changing 
functions would have been a much 
better design from an operational and 
CM point of view. 

• On the other hand, the maturity of 
ACS was less evident. We have had 
numerous problems and “features”. 

A good Ada Program Support Envi- 
ronment would be greatly appre- 
ciated. We wrote 30,000 lines of 
"tool” and configuration management 
scripts. This is significantly more than 
we anticipated supporting. A good 
COTS tool available in a timely man- 
ner would have been a big productiv- 
ity enhancement. 

• The design of our parent libraries and 
sublibraries were important. We 
found ourselves re-creating libraries 
because library parent/child relation- 
ships were hard-coded rather than 
logical. We redid all libraries with 
PSEUDO-DEVICE logicals so that 
successive changes were less painful. 

Project Management 

Equally as important as the Ada lessons 
learned were the lessons we learned in 
managing and controlling a large Ada soft- 
ware development effort. Some of these 
lessons are: 

Standards 

• Our Software Standards and Practic- 
es Manual (SSPM) was HUGE. Far 
too big to be understood or enforced. 
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• Should have made better use of auto- 
mated standards checkers or pretty- 
printer tools. 

• Should have tailored the Language 
Sensitive Editor (LSE) more aggres- 
sively for our local standards and in- 
cluded more templates 

• Standards should be issued, proven, 
taught, understood, reviewed, repro- 
ven, and well documented before any 
code is written. 

Architecture and Schedule 

• Allocate the Right CSCIs. We 
changed the allocation of CSCI’s ear- 
ly in the development effort. Changes 
(reallocations) are difficult to make. 

• Avoid Early Split into CSCI Production 
Groups. We set up a Work Break- 
down Structure (WBS) and Manage- 
ment structure on day one. Therefore 
shifting of work from CSC! to CSCI 
became a continuous struggle. Work 
overall system architecture first before 
parochialism sets in. Set up a mech- 
anism to provide for the overall proj- 
ect good at expense of an individual 
group. 

• Avoid the pressure to accelerate 
schedules. Believe the “Rule of Tens” 
(errors found in a later phase take 1 0 
times longer to fix). Missed goals can 
not be made up. Insist on operation’s 
concepts and equipment (mission 
equipment) designs prior to software 
designs. 

• View interfaces as a “contract” not as 
a goal. Interfaces that change are 
painful. 


• Understand tools required and decide 
on their use well in advance of needs. 
We developed Configuration Manage- 
ment DCL on-the-fly, did not under- 
stand the complexities of Ada CM, 
and shared interface packages (which 
are a good idea, but caused massive 
recompiles). Understand and plan the 
role of tools throughout the whole life- 
cycle. 

• Define and stick to a fixed methodolo- 
gy. We were guilty of making it up as 
we go. Much of the heritage we had 
from our Ada Core Team did not scale 
up into larger development efforts. 
Tools did not easily transition between 
phases. 

• Do more prototyping - especially for 
performance. Make performance esti- 
mates based on Executed Lines Of 
Code (ELOCs) from actual prototypes 
rather than from Lines Of Code 
(LOCs) written or predicted to be writ- 
ten. Consider living (nonjhrowaway) 
prototypes for broadly used “infra- 
structure” code. 

• Use the right language for the right 
function. We made some changes to 
use macro assembler in some critical 
high frequency applications. Device 
driver type functions were very slow in 
Ada as was the high use interprocess 
communication processes. 

• Put Some Teeth into allocating and 
enforcing performance requirements. 
We allocated only very high level re- 
quirements to the CSCIs for CPU and 
Memory performance. These were 
not allocated to lower level compo- 
nents and were therefore untestable 
and unenforceable. 
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• Do Code Walkthrus - set aside a 
team to execute. We relied on peer 
reviews of code. This became a sig- 
nificant schedule pressure on the 
CSCI who concentrated more on their 
own efforts then in a thorough review 
of another CSCIs code. 

• Understand and don’t underestimate 
the entire domain. Understand the 
performance aspects of the COTS 
products and prototype their use. Er- 
rors in COTS are harder to fix be- 
cause of 3rd party involvement. Work 
with COTS can begin earlier since de- 
sign effort is usually not required. The 
effects of the operating system and 
hardware platform are significant, pro- 
topying and an early start is recom- 
mended. 

• Know what you are buying and where 
to use it. For Example, Booch com- 
ponents were excellent at improving 


productivity. However know their per- 
formance characteristics before de- 
ciding where to use them and other 
similar COTS software. 

• Hire Experts - utilize vendor consul- 
tants. On site expertise is the best 
way to fix problems and to get prefer- 
ential access to vendor guru’s and 
other experts. Often you fix problems 
before they happen, since consultants 
can help you with that most difficult 
assessment, determining what it is 
that you don’t know. 

These Lessons Learned represent only a 
small subset of the potential data that can 
be gleaned from GE’s experience on 
STGT. The main lesson to take away from 
this paper is that the language, platform, 
COTS products, tools, etc. are just a 
means to an end and in themselves are re- 
sponsible for neither success nor failure. 
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Software Configuration 

Second TDRSS 
Ground Terminal 

Dec 2-3. 1992 


|WKS CSCI | 

/ 7 — ^ 


DISADPE 
D1S CSCI 
COM CSCI 


SGLT1 EXEC ADPE 
EXC CSCI 
COM CSCI 


K-bandTTC 

USSSA1 

USSSA2 

USSMA 

TTCCSCI 
COM CSCI 


USS CSCI 
COM CSCI 


USS CSCI 
COM CSCI 


USS CSCI 
COM CSCI 


COM CSCI Common Sorvicoe 

DIS CSCI NCC Interface 

EXC CSCI SGLT SchoduOng 

USS CSCI Equipment CMD/MON 

7TC CSCI TDRS/Antenna Control 

WKS CSCI Operator Interfaoe 

SIM CSCI SMTF Simulation 

MDS CSCI SMTFTooU 
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Software Metrics 

Second TDRSS 
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Dec 2-3. 1992 


CSCI 

Size.(LCLG) 

TTC 

100000* 

D1S 

76000* 

USS 

71000* 

EXC 

26000 

WKS 

152000 

COM 

23000 

MDS 

100000 

SIM 

40000 

Total 

588000 


Hours ’ LOC/Hour 


115000: 

.86 

79000 

.96 

58000 

1.22 

23000 

1.13 

56000 

2.7 

37000 

.62 

36000 

2.77 

400001 

1.0 

444000 

1.32 


1 - RaquirMMfit Analysis thru Software l)Mt 

2 - meludM Coat of Common Ground ControUMonttor and Fat* Dateetton 

3 - IndudM Common Ground Controt/Monltor and Fat* Detection 


Chart 5 
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• Ada Project Management Lessons Learned 

- Project Schedule/Structure 

- General Issues 

- Performance/Sizing 

- Reusability 
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Ada Project Management 
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Lessons Learned 
Project Schedulel Structure 

Second TDRSS 
Ground Terminal 

Dec 2-3. 1992 


• Allocate the Right CSCIs 

Changes (Reallocation) are Difficult to Make 

• Avoid Early Spilt into CSCI Production Groups 

Work Overall System Architecture First 

Set up a Mechanism to Provide for the Overall 
Good at Expense of an Individual Group 

• Avoid the Pressure to Accelerate Schedule 

Believe the “Rule of Tens” 

Missed Goals Can Not Be Made Up 

Insist on Operation’s Concepts and Equipment 
Designs Prior to Software Designs 

• View Interfaces as a “Contract” not as a Goal 

Interfaces That Change Are Painful 
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Ada Project Management 
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Lessons Learned 

Second TDRSS 
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General Issues 

Ground Terminal 

Dec 2-3. 1992 


• Understand Tools Required and Decide on their Use 
Well in Advance of Needs 

CM Developed DCL on-the-fly : did not under- 
stand the Complexities of Ada : Shared Interface 
Packages (A Good Idea) Caused Massive Recom- 
piles 

Understand and Plan the Role of Tools Through- 
out the Whole Lifecycle 

• Understand and Don’t Underestimate the Entire Do- 
main 

COTS 

DEC/VMS 

• Prototype and Utilize Prototype Code Everywhere 

• Hire the Right People Then Train/Train/Train 
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Lessons Learned 

Second TDRSS 


General Issues 

Ground Terminal 



Dec 2-3. 1992 


• Define and Stick to A Fixed Methodology 

Define in Advance and Don’t Experiment 
Educate User’s 

• Keep the SSPM Simple - Useful and Easy to Enforce 

• Do Code Walkthrus - Set Aside a Team to Execute 
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Ada Project Management 
Lessons Learned 
Performance! Sizing 


STGT 

Second TDRSS 
Ground Terminal 

Dec 2-3, 1992 


• More Prototyping - Estimates Based on Executed 

• Complex Generics Proved to be Extremely Slow 

• Understand Compile and Link Process (e.g. Compiler 
Eliminates Dead Code But Linker Does Not) 

• Use the Right Language for the Right Function 

• Bad Ada Is Real Baaaaad 

• Put Some Teeth Into allocating and enforcing Perform- 
ance Requirements 
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Ada Project Management 

STuT 


Lessons Learned 

Second TDRSS 
Ground Terminal 


Reusability 

Dec 2-3. 1992 


• Know What You are Buying and Where to Use it 

Booch Components - Not Optimized for Perform- 
ance 

• Don’t Attempt High Level Generics Yet 

Ground Equipment Simulation Is the Wrong 
Choice 

• Provide for Project Wide Reuse Czar 

Avoid Parochialism 

Proactive Search for Opportunities 
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• Ada Lessons Learned 

- Generics 

- Tasking 

- COTS/Platform Dependencies 
Package Structuring/Record Formats 
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Generics 

Ground Terminal 

Dec 2-3. 1992 


• Can be a Performance Problem 

• Are to Debug with Interactive Source Level Debugger 

• Keep Small : Don't Attempt a Reusable Ground Station 

• Restrict Usage to Types as Formal Parameters 

• Keep Them out of the Hands of Amateurs 

Limit to Your Most Experienced People 

Review/Review/and Then Again - Prototype Per- 
formance 
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Tasking 

Ground Terminal 

Dec 2-3. 1992 


• Mistrusted at First - Found Many Appropriate Uses 

Understand the Target Environment/Prototype 

• Provide for Terminate Alternatives - Make Sure a Par- 
ent can Terminate Children 

• Exceptions Must Be Propagated Upward (Free Run- 
ning Tasks Need Some Control) 

• Don’t Substitute Tasks Where Procedures Would Suf- 
fice 

• When Using Tasks - Centralize Control (one writer) 

• If You Plan on a Few Expect Many More 
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STGT 
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By 

Ada Lessons Learned 

HSlfl 

COTSIPlatform Dependencies 

Ground Terminal 

Dec 2-3. 1992 


• Understand Compiler/Linker and Their Interaction 

Don’t Count on Default Order of Elaboration 

• Understand The Whole Domain 

VMS Services Better Than Ada Features 

• Pick COTS With Ada Bindings (Avoid Multiple Transla- 
tions) 

• SQLMODS Proved to Be Workable Interface 

Imbedded SQL was Impossible to Debug 

• Hire Experts - Utilize Vendor Consultants 

• Product Upgrades are Large Undertakings and Come 
at the Most Inopportune Times 

Properly Plan for and Fund Product Upgrades 

• Avoid the Creation of Processes Without Justification 
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Ada Lessons Learned 

Second TDRSS 


PackagelRecord Formats 

Ground Terminal 

Dec 2-3. 1992 


• Limit Scope of Packages - Don’t Try to Encapsulate 
and Entire Object in One Package 

Use Multiple Packages - Each With a Purpose 

Know the Intended Use of the Packages (e.g. 
Senders vs Receivers) 

Avoid Monoliths 

• Don’t Put Database Access into Interface Packages 

• Don’t Combine Loosely Related Types 

• Create Null Instances of a Type as an Initial Value 

• Avoid String Types - Usually Masking an Enumerated 
Type 

• Renaming - Many Differences of Opinions: 

Be Careful 
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Exceptions 
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• Use Only For Real Errors - Very Expensive for Use As 
GOTOs 

• “When Others” obscures origin of exceptions 

• Understand and Plan for Unhandled Exceptions 

Tracebacks and Stack Dumps are Good Debug- 
ging Tools 

Process/System Dumps Have Their Place 

• Specify and Design Expected Levels of Error Handling 
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Project Pressures Force Old Habits to Return 
Solidify Interfaces Under Penalty of Death 
Prototype Everything and Always 
Enforce Performance Allocations 
Focus Reuse and Dedicate Resources 
Restrict Generics 
Don't Be Afraid of Tasks 

Understand the Domain - and Hire Where Necessary 
Limit Scope of Packages 
Be Prepared to Upgrade COTS 
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Marv Zelkowitz, University of Maryland, Facilitator 
Stu Feldman, Executive Director of Computer Systems Research, Bellcore 
John Foreman, Director of STARS Program, Department of Defense 
Susan Murphy, AAS Software Manager, IBM 
Tom Velez, President and CEO, CTA 
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Panel: is Ada Dying? 


m 


• Facilitator: 

- Marvin V. Zelkowitz. NIST/CSL and Department of Computer Science, 
University of Maryland 


• Panelists: 

- Stu Feldman, Executive Director, Computer Systems Research, Bellcore 

- John Foreman, Director of STARS Program, DARPA 

- Susan Murphy, AAS Software Manager, IBM FSC 

- Tom Velez, President and CEO, CTA 


SEL interest in Ada 



• Why SEL interest in Ada? 

- SEL has broadest experience with Ada within NASA 

- SEL has collected much data on the use of Ada (as well as many other 
technologies) 

- SEL has analyzed Ada usage from various perspectives (e,g., see last 
few Workshop proceedings) 

• Results of SEL studies: 

- Value of Ada not unconditionally shown 

- Need to assess current status and plan future processes 
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SEL Ada Projects 



Ongoing FAST 66K} 


I COMPASS 1500K7 


Ada Studies 

POW1TS 68K 



1 parallel Study Completed 
9 Ada Production Products Completed 
All Projects Provide Full SEL Data 
Numerous Studies Completed 

SMEXTELS 61 K 



TONS 38K 

1— — — — — — — 




EUVEDSIM 184lv 
EUVETELS 67K 



jUARSTELS 68 k] 


c 

FDAS 68K | 


GOESIM 92K 


1 GOADA 170K 
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1/85 1/86 1/87 

V. SOFTWARE ENGWEHWC LABORATORY — — 


1/88 


1/89 


1/90 


1/91 


1/92 

SIM* 2-32 
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Ada (and OOD) Impacts on Cost 


Cost To Develop 
Effort per Developed Statement* 


jjgg) FORTRAN 



Cost To Deliver 
Effort per Delivered Statement 



•Ada : Developed Size = 100% New + 30% Old Statements 
FORTRAN: Developed Size = 100% New + 20% Old Statements 


* Development cost per statement has been no cheaper tor Ada 
« Resue potential of Ada Is significant 

• Reuse cost factor has changed in Ada systems 


V SOFTWARE EHQNEERMS LABORATORY 


SEL 
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Language use in Code 500 at Goddard 



Existing New 
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NASA IBM mainframe Ada evaluation 


m 


• Need more development and testing support 

- Two compilers evaluated 

- Multiple source file compilation limited 

- Ada library can be corrupted 

- Inflexible Ada library manager 

- Need better debugger 

- One compiler failed to even compile some modules 

• Need improvement in error handling and error messages 

• Need improvement in performance 

• Result: Could not use IBM mainframe for large-scale NASA Goddard 
development 


Onboard embedded Ada application 



• Goal: Dual 1750 A processors with shared memory to handle onboard 
navigation 

• Environment: T1 1750A hardware. Tartan cross compiler system on VAX 

• Problems: Intermittent communication and shared memory problems. 
Hardware and software vendors could not solve problems. 

• Resolution: Had to fly uniprocessor system with reduced functionality. 


S EL-92-004 page 396 



Positive attributes of Ada 


• Language syntax and semantics are in mainstream language design - an 
outgrowth of FORTRAN, ALGOL and Pascal 

• Language features to aid in large system design, reuse and maintenance 
(e.g., packages, tasking, exceptions, generics) 

• Over 250 validated compilers 

• University use growing — 14 Ada textbooks and use at perhaps 10% of U.S. 
universities (from: November, 1992 Comm, of the ACM) 

• Millions of lines of Ada code for commercial non- military applications - _ 
Examples: Shell Oil for exploration. Motorola for ceBiilar telephones, Boeing 
for 747-400, GE for automated steel manufacturing, NTT (Japan) for 
commercial telecommunications applications. Nokia SoftPlan (Finland) for a 
banking system, plus others 

• Ada-9X revision to solve many of the Kngering problems 


Negative attributes of Ada 



• Hard to team to use well 

• Lack of production quality compilers 

• Performance penalty in certain critical applications 

• Doesn’t handle object oriented design - Impact of C++ 


SEL-92-004 page 397 



Observations 


After 10 years of development ... 

• Growth of courses and textbooks in Ada seems very slow. 

• Does not seem to be a lame scale movement to Ada within non-DoD 
segments of the industry. Most examples are anecdotal. 

• Ada does not yet seem ready within the large mainframe environment at 
Goddard. 

• Yet. seems to be a natural attraction to C and C++. Both have attained 
huge unsupported growth. 

WiH there be supported Ada products in 10 years? 


Summary of issues 


m 


• “Many of the perceived problems with Ada were due to the immaturity of 
early implementations, rather than Raws of the language itself. Some of 
these perceptions linger, even though mature Ada implementations are 
available today and most of the previously identified shortcomings have 
disappeared." - Erhard Ploedereder, Comm, of the ACM, Nov., 1992 


• Is Ada today an economically viable language for buHding software systems? 

• if so, for what dass of projects is it appropriate? 

• if not. what criteria are needed for determining the economic viability of 
Ada (and when should they be met) 
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Panel organization 


m 


• Opening statements: 

- What is your position and why? 

- What are the objective or subjective criteria supporting your position? 

- What actions should the principles be taking (i.e., DoD, NASA, 
contractors) and what w9l Ada be in the next century? 


• Each panelist will talk for up to 10 minutes; then a 5 minute comment by 
panelists on other statements; then general comments or questions from 
workshop attendees 
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Uses and Future 


Niche 

1980 

=> 



2000 

Commercial 

COBOL 

+4GL 

+QUERY LANGUAGE 

+ C++ 

| Scientific/Engineering 

FORTRAN 

+C 

FORTRAN 90, C++ 
C++ 

I Systems 

ASM, C 

C 

Prototyping 

LISP, 

SMALLTALK 

C, PROLOG 

... 

Embedded/Real Time 

ASM, ADA 

C, ADA 

C++, ADA 

S/W Engineering 

ADA 


C++, ADA,...? 

CS Research 

C, LISP 

[ 

CLOS, ML 



txMaun 2 

Sociology 


Lifecycle 

Born/Stillbom 
Born Again? 


Nurture 

Phoenix/Bride of Frankenstein? 


Kinship 

None Allowed 


Support System jn 

Ada Industry «= — Defense Budget 
dt n 


Ecology 

Niches and Competition 
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Unproven Comparisons 


Software Maintainability 

Ada>C 
Ada > C++ 


C++ 


Language Complexity 

Ada 9X > FORTRAN 90 > C++ » C - FORTRAN 77 


Simple - Compiler Difficulty 

Ada 9X > Ada » C++ » C 
Excellent - Compiler Difficulty 

C++ > C » Adas > FORTRAN 


lxMnun4 

Ada Properties 


+ Complete 
+ Supported 
+ Sponsored 
+ Real-Time 
+ Software-Engineering 
? Configuration Support 


Syntax 

Garbage Collection 
Complexity 
Software Support 
Use in Systems ("open") 
Love 
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IS ADA DYING? 


John Foreman 
DARPA/SISTO 
( 703 ) 243-8655 
jtf@scixmu.edu 

kMttjkta n i inn iir man 


posmoN 


• NOT dying, generally in good shape 

— Still maturing 

— Still potential for growth 

— Re al tech insertion and transfer takes long time 

— Is the receptor community mature? 

— Too much ‘over expectation’ 

— DoD still has unique requirements to satisfy 
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CRITERIA FOR JUDGEMENT 


• Ibol quality continually better 

• HW base much improved (32 bit processors, etc) 

• Real projects/real results 

• Use of language for large projects 

• Overseas use 

• Stability and validation are important 
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GETTING TO THE YEAR 2000 

• Planned 9X insertion and use (bindings) 

• Case studies 

• Do something about people: education 

• Need changes to acquisition process 

- life— cycle perspective 

- incremental builds 

- product evolution 

• Process/product considerations 

• Software product line management 

- software architectures 
-COTS 

• Consider effects of downsizing 

- niche market 

- polylingualism 


tastm* mff Hi ii in mm 
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FAA No OTFA0188C 00042 



ADA 

IS 

ALIVE AND HELL 
ON THE 

FAA'S ADVANCED AUTOMATION SYSTEM (AAS) 
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OVER 2.5 MILLION LINES OF NEWLY DEVELOPED CODE (MOSTLY ADA) 

FOUR SEMIS 

KSLOCS 

INITIAL SECTOR SUITE SYSTEM (ISSS) 

1058 

TERMINAL ADVANCED AUTOMATION SYSTEM (TAAS) 

716 

TOWER CONTROL COMPUTER COMPLEX (TCCC) 

257 

AREA CONTROL COMPUTER COMPLEX (ACCC) 

448 
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AAS PROGRAM HJSHLIGHIS (CON'T) 

BY YEAR 2000/ AAS SEGMENTS WILL BE IN USE THROUGHOUT THE USA 
AND FOR FORESEEABLE FUTURE 

-- 432 TOWERS 

- 186 TERMINALS (TRACOH) 

23 ENROUTE CENTERS (ARTCC) 

MANY HUNDREDS OF ADA PROGRAMMERS INVOLVED WITH AAS OVER LIFE OF THE PROGRAM 

AAS IS BASIS OF WORLDWIDE ATC PROGRAMS/BIDS 

— REPUBLIC OF CHINA (TAIWAN) 

— U.K.'S NEW ENROUTE CENTER (NERO 

- GERMANY 
— SWEDEN 

-- EUROCONTROL (ODS) 

- MEXICO 
— BELGIUM 
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FOR ADA TO GROM: 

ADA 9X MUST BE FULLY DOWNWARD COMPATIBLE WITH ADA 83 
(NO CODING CHANGES REQUIRED) 

ELSE 

THESE PRODUCTION SYSTEMS WILL NOT TRANSITION TO Ada 9X 

- HUNDREDS OF Ada PROGRAMMERS WILL NOT EVOLVE TO USE OF 
ADA 9X FEATURES 
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AIR FORCE ADA PROJECTION 


lNCOKTOlATZB 


MAJOR TOM CROAK, USAF 


1991 SURVEY?. 
COBOL 
ADA 

FORTRAN/ 

JOVIAL 

C 

OTHER 


1995 PROJECTION 

40 % 20 % 

10% 40% 

30% 25% 

3 % 10 % 

17% (450 LANG'S.) 5% (250 LANG'S.) 


THERE HAVE BEEN NO ADA WAIVERS SINCE JULY 1090 

•ALL OPERATIONAL SYSTEMS; ADDITIONAL 32M OF ADA CODE UNDER DEVELOPMENT 


r7*= r 

ADA 

INFORMATION CLEARINGHOUSE 

INCORPORATED 



ADA PROJECTS 

EXAMPLES 

• ACADEMIA 

4 

"SUB-SIM" ATTACK SUB SIMULATOR 

• ARMY 

62 

ADVANCE FIELD ARTILLERY TACTICAL DATA SET 
(AFATDS) 

• NAVY 

220 

ADVANCE SURVEILLANCE WORKSTATION 

• MARINE CORPS 

41 

NAVAL FLIGHT RECORD SUBSYSTEM 

• AIR FORCE 

151 

ADVANCED TACTICAL FIGHTER (F22) 

* COMMERCIAL 

111 

BOEING 777 

• GOVT. (NON-DoD) 

58 

ADVANCED AUTOMATION SYSTEM (AAS) 

* INTERNATIONAL 

68 

NETHERLANDS TELEPHONE CONTROL & 
MONITORING SYSTEM 

• OTHER DoD 

7 

SINGLE CHANNEL OBJECTIVE TACTICAL 
TERMINAL (SCOTT) 

TOTAL 

722 



SEL'92-004 page 407 



MYSTIC 


AWK 


ALOOL 


ADA & C++ • BUSINESS CASE ANALYSIS* 


IHCOUOIA1H) 

ADA 

28 COMPANIES W/VAUDATED PRODUCTS 


MARKET AVAILABILITY. 


C*+ 

18 VENDORS OFFER 
C+* 


GOVT. CONTROLLED/ANSI & tSO 
STANDARDS 

YES 

22 UNIVERSITIES & 13 DoD INSTALLATIONS 
78.8 


210 (SLOC/MM) 

<153 DATA POINTS) 


65 (VSLOC) 

(153 DATA POINTS) 


24 <153 DATA PTS.) 


1 (153 DATA PTS) 


1631 

(23% HIGHER) 
1738 

(24% HIGHER) 


STRONG 

ST AP ARP1Z ATJflM 

CROSS COMPILATION 


EDUCATION/TRAINING 

FEATURE COMPARISON * 
(OUT OF 100) 

PRO DU CTI VI T Y 

(NORM: 183 ALL LANG. 


COST 

(NORM: 70 ALL LANGUAGES) 


NO VALIDATION OR 
STANDARD EXIST 

NO 

4 UNIVERSITIES 
63.9 

187 (SLOC/MM) 

(38 DATA PTS.) 

55 

(23 DATA PTS.) 


AVOt ERROR bates (PER KSLPC1 4 

INTEGRATION 31 (23 DATA PTS.) 

(33: NORM ALL LANGUAGES) 


FORMAL QUAL TEST 

(3: NORM ALL LANGUAGES.) 


3 (23 DATA PTS.) 


ADA COCOMO COST ANALYSIS 
MIS 1324 

C3 SYSTEMS 1401 


• BASED ON U3. AIR FORCE STUDY 

~ BY SEI FOR APPLICATIONS INFO R NATION/ C3 SYSTEMS 


JOVIAL 
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nCOtfOMKD 


ADA AN EIGHTEEN YEAR SCOREBOARD 


OBJECTIVE 


RESULT 


SCORE 


SINGLE (DoD-1) HOL 


WE (CTA) SEE ADA MANDATED IN 
VIRTUALLY 100% OF DoD RFPs + 


SUPPORT MODERN 
SOFTWARE ENGINEERING 
TECHNIQUES 


YES: THROUGH STRONG TYPING 
PACKAGING, AND OTHER FEATURES + 


PROVIDE AN “ADA" 
ORIENTED PROGRAMMING 
ENVIRONMENT 


NO: CLEARLY, THE PROMISES OF 
CAIS, APSE, NOT REALIZED 


INCREASE OF PRODUCTIVITY NO CLEAR, CONCLUSIVE RESULTS 

• APPARENT RESULT IS SAME AS 

OTHER LANGUAGES NEUTRAL 


DECREASE LC SOFTWARE EVIDENCE IS POSITIVE - LESS 

MA1NTENACE (EVOLUTION) COST ERRORS IN OAM 4 


STANDARDIZATION 


YES: ANSI A ISO 


+ 


CONTROLLED, STABLE YES: THROUGH GOVT. SUPPORT 

COMPILER IMPLEMENTATION + 


CLEAR “GRASS ROOTS" USAGE NO: CERTAINLY NOT LIKE "C" 

(IN COMMERCE, ACADEMIA) 


OVERALL RESULT: POSITIVE 
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Appendix A: Attendees 


Abd-El-Hafiz, Salwa K., 
University of Maryland 

Addelston, Jonathan D., 
Planning Research Corp. 

Agresti, Bill W., MITRE 
Corp. 

Aikens, Stephen D., DoD 

Allen, Julia, Software 
Engineering Institute 

Allen, Russ, IRS 

Anderman, Al, Rockwell 
SSD 

Anderson, Barbara, Jet 
Propulsion Lab 

Anderson, Jim, IRS 

Angier, Bruce, Institute for 
Defense Analyses 

Arnold, Robert S., Sevtec 

As till, Pat, Centel Federal 
Services 

Austin, James L., IRS 

Ayers, Everett, Ayers 
Associates 

Bachman, Scott, DoD 

Bacon, Beverly, Computer 
Sciences Corp. 

Bailey, Carmine M., 
McDonnell Douglas 

Bailey, John, SEL 

Balick, Glenn, DoD 

Barbara, Edward K., U.S. Air 
Force 

Barbour, Ed, U.S. Air Force 

Barnes, Bruce H., National 
Science Foundation 

Barnette, Randy, Hughes 
STX 

Barnhart, Don, Boeing 
Aerospace Co. 

Basch, Bill, Boeing 
Computer Support 
Services Co. 

Basili, Vic, University of 
Maryland 

Bates, Bob G., Lockheed 
Space Operations 

Baumert, John H., Computer 
Sciences Corp. 


Bearchell, Deborah J., 
Computer Sciences 
Corp. 

Beatty, Kristin, HT Research 
Institute 

Belle, Jeffery C., Logicon, 

Inc. 

Beswick, Charlie A., Jet 
Propulsion Lab 

Billick, Ron, Bell Atlantic 

Binegar, Scott, Computer 
Sciences Corp. 

Biondi, Marisa, IRS 

Bishop, Steven, Naval Air 
Warfare Center 

Bisignani, Margaret, MITRE 
Corp. 

Bissonette, Michele, 
Computer Sciences 
Corp. 

Blackwelder, Jim, Naval 
Surface Warfare Center 

Blagmon, Lowell E., Naval 
Center for Cost Analysis 

Blankenship, Donald D., U.S. 
Air Force 

Blankenship, Gordon, U.S. 
Air Force 

Bloodgood, Pete, IRS 

Blough, Lyn, Computer 
Sciences Corp. 

Blum, Bruce I., Applied 
Physics Lab 

Bogdan, Robert J., Computer 
Sciences Corp. 

Boger, Jacqueline, Computer 
Sciences Corp. 

Boland, Dillard, Computer 
Sciences Corp. 

Bond, Jack, DoD 

Boon, Dave, Computer 
Sciences Corp. 

Booth, Eric, Computer 
Sciences Corp. 

Borger, Mark W., Software 
Engineering Institute 

Boyce, Glenn W., MITRE 
Corp. 

Bozenski, Richard, DoD 

Bozoki, George J., Lockheed 


Bradley, Stephen, MMS 
Systems 

Bradshaw, Royce, NATO 

Brandt, Thomas C., Software 
Engineering Institute 

Bredeson, Mimi, Space 
Telescope Science 
Institute 

Briand, Lionel, University of 
Maryland 

Brill, Gary, IRS 

Brisco, Phil C., Hughes STX 

Brown, Robert E., Hughes 
Aircraft Co. 

Brownsword, Lisa L., 
Computer Sciences 
Corp. 

Brownsword, Robert J., 
Rational 

Bruhn, Anna, Jet Propulsion 
Lab 

Bullock, Steve, IBM 

Bunch, Aleda, Social 

Security Administration 

Burell, Billie, IBM 

Bums, Patricia, Computer 
Sciences Corp. 

Butler, Sheldon, Computer 
Sciences Corp. 

Butterworth, Paul, Hughes 
STX 

Button, Janice, DoD 

Button, Judee, IRS 


Caldiera, Gianluigi, 

University of Maryland 

Calvo, Robert, Paramax 
Aerospace Systems 

Cantalupo, Joy, IIT Research 
Institute 

Capraro, Gerald T., Karman 
Sciences 

Card, Dave, Computer 
Sciences Corp. 

Carlin, Catherine M., Dept, 
of Veterans Affairs 

Carlisle, Candace, 
NASA/GSFC 
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Carlson, J., Computer 
Sciences Corp. 

Carpenter, Maribeth B., 
Software Engineering 
Institute 

Carruthers, Mary W., BT 
Research Institute 

Carter, Mike, U.S. Air Force 

Cecil, Robert W., Computer 
Sciences Corp. 

Cheramie, Randy, Loral 
Space Information 
Systems 

Cheung, Helen, Tandem 
Computers, Inc. 

Chiem, I-Ming Annie, 
Computer Sciences 
Corp. 

Chimiak, Reine A., 
NASA/GSFC 

Chittister, Clyde, Software 
Engineering Institute 

Chiverella, Ron, PA Blue 
Shield 

Cho, Kenneth, U.S. Air Force 

Choquette, Carl, BT 
Research Institute 

Choudhary, Rahim, Hughes 
STX 

Christophe, Debou, Alcatel- 
Elin Research Centre 

Chu, Martha, Computer 
Sciences Corp. 

Chu, Richard, Loral AeroSys 

Church, Vic, Computer 
Sciences Corp. 

Clapp, Judith A., Ml'lRE 
Corp. 

Clark, Carole A., Dept of 
Veterans Affairs 

Clark, Peter G., TASC 

Clarke, Margaret J., IBM 

Coleman, Carolyn, IIT 
Research Institute 

Condon, Steven E., 
Computer Sciences 
Corp. 

Connor, David, Computer 
Sciences Corp. 

Cook, John F., NASA/GSFC 

Coon, Richard, Computer 
Sciences Corp. 

Cornett, Lisa K., U.S. Air 
Force 


Couchoud, Carlton B., Social 
Security Administration 

Cover, Donna, Computer 
Sciences Corp. 

Crafts, Ralph E., Ada 
Software Alliance 

Creecy, Rodney, Hughes 
Aircraft Co. 

Crehan, Dennis J., Loral 
AeroSys 

Crops, Dick, Paramax 
Aerospace Systems 

Cuesta, Ernesto, Computer 
Sciences Corp. 


D’Agostino, Jeff, The 
Hammers Co. 

Dabrowski, Christopher, 
NIST 

Daku, Walter, Paramax 
Aerospace Systems 

Daney, William E„ 
NASA/GSFC 

Dangerfleld, Olie B., 
Computer Sciences 
Corp. 

Daniels, Charles B., Paramax 
Aerospace Systems 

Daniels, Helen, IRS 

Davis, Ann, Computer 
Sciences Corp. 

Davis, C., Computer 
Sciences Corp. 

Day, Nancy A., Naval 

Surface Warfare Center 

Day, Orin, Hughes STX 

Decker, William, Computer 
Sciences Corp. 

Denney, Valerie P., Martin 
Marietta 

Dhaliwal, Avtar, SEER 
Systems Corp. 

DiNunno, Donn, Computer 
Sciences Corp. 

Dikel, David, Applied 
Expertise, Inc. 

Diskin, Barbara N., Census 
Bureau 

Diskin, David H., Defense 
Information Systems 
Agency 

Diven, Jeff, IRS 

Doland, Jerry T., Computer 
Sciences Corp. 


Dolgaard, Jon, Sunquest 
Information Systems 

Donnelly, Richard E., DoD 

Dortenzo, Don, Fairchild 
Space Co. 

Dowen, Andrew, Jet 
Propulsion Lab 

Drake, Anthony M., 

Computer Sciences 
Corp. 

Driesman, Debbie, Computer 
Sciences Corp. 

Duncan, Scott P., 

BELLCORE 

Duniho, Mickey, DoD 

Dunn, Joseph, Computer 
Sciences Corp. 

Durak, Tom, TAD 
Consulting 

Duvall, Lorraine, Syracuse 
University 

Dyer, Michael, IBM 

Edelson, Robert, Jet 
Propulsion Lab 

Edlund-OMahony, Sheryl J., 
USA, ISSOCW 

Eichmann, David, University 
of Houston-Clear Lake 

Ellis, Walter, IBM 

Elovitz, Honey, MITRE 
Corp. 

Elston, Judson R., Boeing 
Aerospace Co. 

Elwood, Todd W., Computer 
Sciences Corp. 

Emerson, Curtis, 
NASA/GSFC 

Emery, Richard D., Vitro 
Corp. 

Engelmeyer, William J., 
Computer Sciences 
Corp. 

Evan co, William, MURE 
Corp. 

Evers, J. W., Paramax 
Aerospace Systems 

Fagan, Michael, Michael 
Fagan Associates 

Faller, Ken, HTASC 

Farah, Jocelyne, U.S. Air 
Force 
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Farrell, Mary Ann, Logicon, 
Inc. 

Farrell, William T., DSD 
Laboratories, Inc. 

Fauerby, John, Computer 
Sciences Corp. 

Feldman, Stuart, 

BELLCORE 

Ferguson, Frances, Stanford 
Telecommunications, 

Inc. 

Fenigno, Peter M., RJO- 
Enterprises, Inc. 

Fink, Mary Louise A., 
Treasury Department 

Finley, Doug, Paramax 
Aerospace Systems 

Fleming, Barbara 

Fleming, Judy K., IBM 

Foreman, John, Software 
Engineering Institute 

Forsythe, Ron, 

NASA/Wallops Flight 
Facility 

Fouser, Thomas J., Jet 
Propulsion Lab 

Fox, Raymond, DoD 

Franklin, Jude E., Planning 
Research Corp. 

Friedman, Seymour R., 
MITRE Corp. 

Fuentes, Wilfredo, Logicon, 
Inc. 

Gallagher, Barbara, DoD 

Gaylord, Jerry, HT Research 
Institute 

Gehrmann, Paul, IBM 

Geil, Ester, Westinghouse 

Geil, Leana M., Dept Of 
Veterans Affairs 

Gieser, Jim, Paramax 
Aerospace Systems 

Gillam, Michael, OAO Corp. 

Gire, Carey, Loral AeroSys 

Giusti, Ronald V., MITRE 
Corp. 

Glascock, Robin, Tandem 
Computers, Inc. 

Glass, Robert L., Computing 
Trends 

Godfrey, Sally, NASA/GSFC 

Gogia, B. K., Datamat 
Systems Research, Inc. 


Golden, John R., Rochester 
Institute of Technology 

Golding, Annetta, Census 
Bureau 

Gordon, Del, Paramax 
Aerospace Systems 

Gonnally, John M., TRW 

Gosnell, Arthur B., U.S. 

Army Missile Command 

Gotteibam, Donald, East 
Tennessee State 
University 

Graham, Robert P., U.S. Air 
Force 

Gray, Carmella, CRM 

Gray, James H., Computer 
Sciences Corp. 

Green, David, Computer 
Sciences Corp. 

Green, Scott, NASA/GSFC 

Greene, Joseph B., Booz, 
Allen & Hamilton, Inc. 

Gregory, John G., 
Westinghouse 

Grondalski, Jean F., 

Computer Sciences 
Corp. 

Groveman, Brian S., 
Computer Sciences 
Corp. 

Gu, Dechang, North Carolina 
A&T State University 

Guillebeau, Pat, New 
Technology, Inc. 

Gupta, Lakshmi, Loral 
AeroSys 

Hall, Dana L., SAIC 

Hall, John E., DoD 

Hall, Ken, Computer 
Sciences Corp. 

Hall, Susan M., SofTech, Inc. 

Halpine, Scott, Loral 
AeroSys 

Halterman, Karen, 
NASA/GSFC 

Hankins, Dick, General 
Dynamics 

Hanna, Susan, Beckman 
Instruments, Inc. 

Harrington, Keith, U.S. Air 
Force 

Harris, Barbara, IRS 


Harris, Bernard, 

NASA/GSFC 

Harris, Mary, Hughes 
Aircraft Co. 

Hashmi, Awais A., Digital 
Systems 

Hatch, Ada, IRS 

Hausler, Philip A., IBM 

Hazle, Marlene, MITRE 
Corp. 

Hearn, Rick, Ollila Industries 

Heller, Gerard H., Computer 
Sciences Corp. 

Hendrick, Christine, 
Computer Sciences 
Corp. 

Hendrick, Robert B., 
Computer Sciences 
Corp. 

Hendrzak, Gary, Booz, Allen 
& Hamilton, Inc. 

Hetmanski, Christopher, 
University of Maryland 

Hill, Ken, Paramax 
Aerospace Systems 

Hilldrup, Kerry C., Hughes 
STX 

Hills, Frederick, Software 
Productivity Consortium 

Hladry, John, Boeing 
Computer Support 
Services Co. 

Ho, N., Computer Sciences 
Corp. 

Hoffman, Dan, University of 
Victoria 

Hoffman, John C., Sunquest 
Information Systems 

Hoffmann, Kenneth, Ryan 
Computer Systems 

Holmes, Barbara, CRM 

Holmes, Joseph A., IRS 

Hover, Karen E., Martin 
Marietta 

Hsiah, K., Computer 
Sciences Corp. 

Huang, Bing, FAA 

Hull, Larry, NASA/GSFC 

Hung, Joshua C., FAA 

Huza, Marilyn, IRS 

Hynes, Lois, IRS 

Hgenftttz, Charles, IRS 


SEL-92-004 page 413 



Ippolito, Laura, NIST 

Iscoe, Neil, EDS Research, 

Inc. 

Iskow, Lany, U.S. Census 
Bureau 

Jackson, Ann, University of 
Victoria 

Jackson, Lyn, Logicon, Inc. 

Jackson, Steve, U.S. Air 
Force 

James, Chris, Computer 
Sciences Corp. 

James, Jason S., DoD 

Jay, Elizabeth M., 
NASA/GSFC 

Jeletic, Jim, NASA/GSFC 

Jeletic, Kelly A., 

NASA/GSFC 

Jenkins, John O., City 
University 

Jenkins, Jr, Robert, Computer 
Sciences Corp. 

Jepsen, Paul L., Jet 
Propulsion Lab 

Jessen, William J., General 
Electric 

Jilek, Simi S., U.S. Dept, of 
Energy 

Johnson, Kent A., Software 
Productivity Consortium 

Jones, Christopher C., HT 
Research Institute 

Jones, Deborah M., FAA 

Jones, Mel, Applied 
Expertise, Inc. 

Jones, Nancy A., MITRE 
Corp. 

Jordano, Tony J., S AIC 

Kavanagh, Dennis M., 
Computer Sciences 
Corp. 

Kelly, John C., Jet Propulsion 
Lab 

Kelly, Sharon C., Hanis 
Corp. 

Kemp, Dennis, Hughes STX 

Kemp, Kathryn M., 
NASA/HQ 

Kester, Rush, Computer 
Sciences Corp. 

Kieckhefer, Ron, Computer 
Sciences Corp. 
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Kim, Seung, Computer 
Sciences Corp. 

Kirkendall, Thomasin, NIST 

Kirkpatrick, Diane, Ball 
Aerospace 

Kistler, David M., Computer 
Sciences Corp. 

Klitsch, Gerald, Computer 
Sciences Corp. 

Knapp, Andy, Bell Atlantic 

Knoell, Roger, U.S. Air 
Force 

Koeser, Ken, Vitro Corp. 

Konopka, Joseph J., 

Computer Sciences 
Corp. 

Kontson, Kalle R., ITT 
Research Institute 

Kopperman, Stuart, Systems 
Research & Applications 
Corp. 

Kosloski, Joe, IRS 

Kovin, Steven E., Computer 
Sciences Corp. 

Kramer, Nancy, Viar & Co. 
/Dyncoip 

Kramer, Teresa L., DoD 

Kristof, Dave, U.S. Air Force 

Kudlinski, Robert A., 
NASA/LaRC 

Kurihara, Tom, Logicon, Inc. 
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International S/W 
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NASA/GSFC 

Lawlor, Tran, Bell Atlantic 

Lawrence, Raymond, 
LMcDonnell Douglas 
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Sciences Corp. 


Lee, Thomas S., Paramax 
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College of Science 

Lemmon, Doug, University 
of Maryland 
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Levitt, David S., Computer 
Sciences Corp. 

Lewicki, Scott A., Jet 
Propulsion Lab 
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of Maryland 
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Sciences Corp. 
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Lindsay, Orlando, Computer 
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University 
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Force 
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Sciences Corp. 
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Engineering Sciences, 
Inc. 
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& Hamilton, Inc. 

Loy, Patrick H., Loy 
Consulting, Inc. 
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Mohallatee, Michael, 
Computer Sciences 
Corp. 
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Mulville, Daniel, NASA/HQ 

Munkeby, Steve, Martin 
Marietta 

Murphy, Susan, IBM 

Murtha, Kimberly N., 
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Patrick, Debora, HT Research 
Institute 

Patterson, F., G., NASA 
SSFPO 

Patton, Kay, Computer 
Sciences Corp. 
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